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1. 


BACKGROUND 


As  more  sophisticated  systems  are  required  to  combat  rapidly  growing  threats,  the  Air 
Force  faces  greater  challenges  in  getting  these  systems  from  an  R&D  concept  to 
production.  A  significant  challenge  is  dealing  with  the  level  of  design  complexity 
imposed  by  these  systems.  As  software  replaces  hardware  to  accommodate  the  smarts 
built  into  a  system  to  make  it  user  friendly,  the  dimensionality  of  the  design  problem 
grows  exponentially.  As  systems  get  smarter,  they  depend  upon  more  information  to 
operate.  This  implies  interfaces  with  other  systems  in  the  Global  Information 
Enterprise  (GIE)  -  to  request  and  obtain  information,  and  to  publish  and  subscribe  data  to 
meet  shrinking  time  requirements.  At  the  same  time,  breadboards  and  brassboards  are 
becoming  very  expensive  to  build.  Fortunately,  they  are  becoming  less  important  due  to 
the  software  nature  of  these  systems.  Much  of  the  guts  of  a  system  today  lay  in  huge  sets 
of  imbedded  algorithms  in  general  purpose  processors  that  provide  the  smarts.  Testing 
these  algorithms  with  all  of  the  external  interfaces  they  must  support  is  becoming  most 
difficult  and  expensive.  To  meet  these  challenges,  a  new  approach  to  designing  and 
testing  these  complex  systems  has  evolved.  This  approach  uses  simulation. 


2.  INTRODUCTION 

This  is  the  Final  Report  from  PSI  on  our  participation  in  the  second  round  of  effort  on 
the  formation  of  the  GIESim  Laboratory.  Since  the  beginning  of  this  effort,  the  goals  of 
the  GIESim  effort  have  remained  the  same.  GIESim  must  be  capable  of  predicting  the 
end-to-end  performance  and  survivability  of  globally  distributed  information  exchange 
and  management  applications,  such  as  the  Joint  Battlespace  Infosphere  (JBI),  Deployable 
Theater  Information  Grid  (DTIG),  and  Information  For  Global  Reach  (IFGR).  It  is  aimed 
at  providing  a  powerful  and  dynamic  generic  modeling  and  simulation  framework  as  a 
baseline  for  continuing  simulations  of  future  instantiations  of  JBI  and  other  applications. 

In  PSPs  view,  such  a  simulation  facility  can  be  used  to  support  development  and  testing  of  many 
systems  in  various  stages  of  their  evolution,  e.g.,  requirements  analysis,  system  design,  interface  design, 
system  testing,  and  support  for  design  and  test  of  system  upgrades.  In  effect,  GIESim  can  provide  a 
laboratory  for  defining,  designing,  and  testing  complex  communications  and  information  networking 
components  of  the  GIE.  It  can  support  live  field  testing  by  helping  to  plan  tests  as  well  as  augment  and 
extend  test  capabilities  beyond  what  is  achievable  with  the  actual  hardware.  Given  that  simulations  have 
been  validated,  they  can  support  the  interpolation  and  extrapolation  of  limited  amounts  of  test  data,  a  major 
factor  in  system  evaluations  and  decisions. 

This  Final  Report  describes  activities,  work  done,  and  results  of  building  the  multi-simulation 
demonstration  for  the  SAB  review.  This  report  also  presents  an  overview  of  the  simulation  architectures  of 
the  GSS-based  simulations  and  highlights  the  changes  made  to  support  the  SAB  GIESim  multi-simulation 
demonstration.  This  Final  Report  also  presents  an  overview  of  the  “lessons  learned”  in  the  development  of 
the  GIESim  demonstration,  and  suggests  future  activities  and  directions  to  ensure  the  successful  evolution 
and  application  of  the  GIESim  Laboratory. 
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3. 


BRIEF  STATEMENT  OF  THE  PROBLEM 


The  vision  of  the  Global  Information  Enterprise  (GIE)  is  to  move,  proeess,  manage, 
and  proteet  the  C2ISR  information  that  supports  the  funetions  of  Global  Awareness  and 
Dynamic  Planning  and  Execution.  The  mission  of  GIE  is  to  link  aerospace  assets  in¬ 
theater  and  globally,  to  integrate  C2  &  ISR  networks,  to  defend  critical  information 
systems  from  cyber  attack,  and  to  develop  new  information  processing  and  management 
techniques. 

Most  large-scale  force  level  simulations  assume  perfect  communications.  This  can 
lead  to  significant  limitations  and  inaccuracies  in  the  results  obtained  from  running  these 
simulations.  Tools  are  needed  to  bridge  these  communications  modeling  gaps. 

The  GIESim  project  is  a  simulation  development  program  to  define,  design  and  implement  a 
Modeling  and  Simulation  (M&S)  framework  for  the  GIE.  Within  the  GIESim  framework,  users  will  be 
able  to  execute,  via  a  common  interface,  multiple  communications  and  network  M&S  tools  to  most 
effectively  and  efficiently  analyze  candidate  communications  architectures  and  technologies.  The  GIESim 
will  interface  with  other  M&S  tools  (e.g.,  force-level  simulations  and  detailed  hardware  system  models)  to 
provide  the  appropriate  level  of  M&S  fidelity  and  processing  speed  for  the  broad  spectrum  of  M&S  tasks. 
The  GIESim  user  base  will  span  from  advanced  technology  researchers  to  communications  network 
architects  to  mission  planners. 

A  predictive  framework  needs  to  be  established  to  ensure  that  battlespace 
information  platforms  are  supported  with  required  communications  technologies. 

This  framework,  embodied  in  the  GIESim  lab,  must  be  capable  of  predicting  end- 
to-end  performance  and  survivability  of  globally  distributed  information  exchange 
and  management  applications,  such  as  the  Joint  Battlespace  Infosphere  (JBI). 

What  will  it  take  to  ensure  the  success  of  GIESim?  What  does  success  imply? 
Based  upon  prior  experiences  in  this  area,  PSI  offers  the  following  thoughts.  One  can 
envision  a  simulation  laboratory  where  program  managers  sign  up  to  make  use  of  the 
facilities.  They  are  motivated  because  they  can  save  precious  time  and  money  getting 
answers  to  complex  technical  questions.  They  can  use  the  facility  to  demonstrate  the 
level  of  operational  capability  of  systems  under  test.  The  results  obtained  can  be 
validated  by  targeted  testing  and  in-depth  analysis.  Most  importantly,  this  laboratory 
evolves  to  be  a  reliable  proving  ground  to  support  decisions  on  fielding  systems.  It  also 
provides  a  repository  for  knowledge  of  what  it  takes  to  ensure  successful  use  of  R&D 
funding. 

Given  that  the  above  vision  is  desired,  what  will  it  take  to  ensure  its  success?  Success  will  be 
measured  in  the  eyes  of  the  beholders  -  the  users  and  the  decision  makers  for  funding.  If  the  JBI  program  is 
the  important  first  user,  what  is  needed  to  ensure  its  successful  use?  What  is  the  JBI  program  looking  for  in 
terms  of  a  simulation  environment?  What  investments  are  needed  to  ensure  JBI  can  make  good  use  of 
GIESim?  Can  these  investments  be  justified  for  JBI  alone?  If  not,  how  can  they  be  leveraged  with  other 
programs.  What  are  the  milestones,  time  frames  and  resources  required  to  ensure  the  success  of  GIESim  in 
the  long  mn?  PSI  is  committed  to  help  answer  these  questions. 

For  2003,  the  GIESim  AFRL/IFGC  leadership  team  has  set  one  goal  for  the  GIESim  Lab:  design 
and  develop  an  initial  proof  of  concept,  heterogeneous  multi-simulation  environment  targeted  for 
demonstration  to  the  AFRL  Scientific  Advisory  Board  (SAB)  in  the  fall.  The  scenarios  for  this 
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demonstration  will  involve  selected  sub-components  of  the  Deployable  Theater  Information  Grid  (DTIG). 
The  General  Simulation  System  (GSS)  from  PSI  has  been  identified  as  a  critical  part  in  this  demonstration 
system. 
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4. 


REVIEW  OF  WORK  ACCOMPLISHMENTS 


This  section  presents  background  on  the  SAB  multi-simulation  demonstration,  an  overview  of  PSI 
work,  then  presents  details  on  the  work  done  by  PSI  for  the  demonstration. 


4.1  BACKGROUND  ON  THE  MULTI-SIMULATION 
DEMONSTRATION 

For  round  two  (FY03)  of  the  evolution  of  GIESim  ,  the  GIESim  Leadership  requested  that  several 
teams  cooperate  to  develop  a  multi-simulation  demonstration  of  the  GIESim  concept  of  integrating  diverse 
simulations  (primarily  of  communications)  by  building  a  framework  with  underlying  HLA  connectivity. 
This  multi-simulation  was  to  “model”  aspects  of  the  Deployable  Theater  Information  Grid  (DTIG).  PSI 
was  one  of  the  companies  chosen  to  participate  in  the  creation  of  this  DTIG  Multi-Simulation 
Demonstration  (DMSD).  PSI  proposed  to  use  it’s  high-fidelity  simulation  of  JTIDS/Link-16  for  a  central 
part  of  the  communications  modeling  for  DMSD,  and  also  proposed  to  use  it’s  SAT_COM  simulation  to 
model  satellite  communications.  PSI  also  offered  a  stretch  goal  of  interfacing  SAT_COM  to  the  Satellite 
Tool  Kit  (STK)  from  Analytical  Graphics  to  obtain  satellite  orbits.  These  proposals  were  accepted.  In 
addition,  the  rich,  interactive  graphics  capabilities  of  the  GSS  Run-Time  Graphics  (RTG)  would  serve  as  a 
central  means  to  visualize  key  behavior  and  metrics  in  the  demonstration.  The  DMSD  is  aimed  at  the  SAB 
Review  now  scheduled  for  November  ‘03.  Greg  Hadynski  of  DTIG  reviewed  the  DMSD  descriptions  and 
agreed  that  DMSD  represented  a  piece  of  the  “as-is”  DTIG  situation. 


Figure  1  -  DTIG  Multi-Simulation  Demo  (DMSD)  Scenario^ 

DMSD  would  involve  a  scenario  in  which  different  simulation  components  compute  their  own 
latency  and  add  it  to  the  accumulating  latency  as  a  large  UAV  Image  message  works  it’s  way  through 
various  communications  and  information  path-ways.  Figure  I  shows  an  illustration  for  the  scenario  created 
for  the  DMSD  by  the  GIESim  team. 

The  physical  architecture  of  the  GIESim  DMSD  simulations  is  shown  in  Figure  2.  All  simulations 
typically  run  on  separate  PCs  and  are  connected  to  a  LAN  that  is  typically  running  on  a  separate  Hub  to 
isolate  the  GIESim  DMSD  from  other  LAN  traffic.  The  HLA  Run  Time  Infrastructure  (RTI)  can  run  on 
any  of  the  simulation  PCs  or  a  separate  PC.  In  Figure  2,  IP  refers  to  the  use  of  TCP/IP  sockets,  and  HLA 
refers  to  HLA  connections  on  the  LAN.  Note  that  GSS  has  built-in  support  for  TCP/IP  sockets  by  virtue  of 
IP  Channel  Resources.  This  GSS  capability  is  discussed  later. 


^  From  a  poster  developed  by  SRC  with  the  GIESim  team  for  the  SAB  Review 
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Physical  Architecture  of  GIESim  SAB  Simulation  Demo 


Figure  2  -  Physical  Architecture  of  the  GIESim  Demo 


This  scenario  created  for  the  DMSD  by  the  GIESim  team  has  the  following  sequence  of  events  : 

1 .  A  Predator  UAV  being  modeled  by  SAIC  using  OPNET  would  fly  over  Korea  looking  for  targets. 
This  simulation  would  publish  HLA  interactions  that  would  “fly”  the  UAV  in  the  visual  space  of 
the  JTIDS  simulation. 

2.  At  some  point,  the  Predator  UAV  would  capture  an  image  of  a  Time  Critical  Target  (TCT)  on  the 
ground  in  a  Korean  theater  of  operation.  When  this  happens,  an  extra  field  in  the  HLA  interaction 
will  cause  the  UAV  to  “flash”  in  the  JTIDS  simulation  to  indicate  image  “capture”. 

3.  The  Predator  UAV  would  send  the  image  to  an  Air  Operation  Center  (AOC)  component  in  Korea 
via  HLA  interactions  to  JBISim,  which  is  a  simulation  of  the  Joint  Battlespace  Infosphere. 

4.  Modeled  entities  in  JBISim  would  then  send  the  image  via  HLA  to  the  JTIDS  gateway  for 
transmission  over  JTIDS  via  the  GSS  JTIDS  simulation. 

5.  The  message  sent  through  the  JTIDS  network  would  be  received  by  another  gateway  in  Korea  for 
transmission  over  a  satellite  network  to  the  Continental  US  (CONUS).  The  JTIDS  simulation 
gateway  would  send  the  message  to  the  SAT_COM  simulation  using  a  GSS  IP  Channel  interface. 

6.  The  SAT_COM  simulation  Korean  gateway  would  receive  the  message  from  the  IP  Channel 
interface  and  send  it  to  the  satellite  uplink.  This  satellite  network  was  modeled  in  GSS  with 
satellite  orbits  obtained  from  STK. 

7.  At  the  SAT_COM  satellite  down-link  gateway  in  CONUS,  the  received  message  would  be 
published  via  HLA  for  arrival  at  another  component  of  JBISim. 

8.  JBISim  would  model  CONUS  entities  that  eventually  generate  an  annotated  version  of  the  original 
image  to  send  back  to  Korea  to  direct  a  strike  on  the  ground  TCT.  An  HLA  interaction  would  be 
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published  to  send  the  image  to  the  CONUS  gateway  of  the  SAT  COM  simulation  for  uplink  to 
Korea. 

9.  The  SAT_COM  downlink  gateway  in  Korea  would  receive  the  message  and  send  it  to  the  JTIDS 
simulation  via  the  GSS  IP  Channel  interface. 

10.  When  received  by  the  JTIDS  simulation,  the  gateway  would  send  the  message  over  JTIDS  to  the 
gateway  associated  with  the  AOC. 

1 1 .  The  receiving  gateway  in  the  JTIDS  simulation  would  then  publish  an  HLA  interaction  to  send  the 
message  to  modeled  entities  within  JBISim. 

12.  Modeled  entities  in  JBISim  would  exchange  messages  with  each  other. 

13.  Eventually  a  strike  command  is  issued  via  an  HLA  interaction  to  a  strike  platform  being  modeled 
in  the  JTIDS  simulation. 

14.  When  the  HLA-based  strike  message  is  received  by  the  JTIDS  simulation  it  is  sent  to  the  strike 
platform  over  a  JTIDS  Net  defined  for  this  purpose. 

15.  When  the  strike  platform  receives  the  message  it  would  send  an  acknowledgement. 

16.  The  JTIDS  gateway  would  receive  the  acknowledgement  and  publish  an  HLA  interaction  to  send 
it  to  JBISim. 


A  view  of  the  GSS-based  simulation  components  is  shown  in  figure  3.  This  figure  shows  the 
HLA  Entity  IDs  defined  for  the  GIESim  DMSD,  and  the  HLA  and  TCP/IP  socket  connectivity  of  the  PSI 
simulations  into  the  GIESim  DMSD. 
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Also  shown  in  Figure  3  are  new  icons  that  were  created  for  the  new  GIESim  gateways  in  JTIDS 
and  SAT_COM.  In  addition  to  creating  gateway  icons  for  the  JTIDS  simulation,  the  simulation  was 
modified  to  “recognize”  these  icons  as  having  JTIDS  radios.  This  is  important  for  the  demo  for  two 
reasons.  First,  as  radio  equipment  icons,  the  AOC_GW  and  JTIDS_SAT_GW  icons  can  serve  as  sources 
and  destination  for  JTIDS  Operational  Nets.  This  capability  is  needed  to  support  the  JTIDS  networking  for 
the  GIESim  messages.  Second,  as  radio  icons,  the  JTIDS  simulation  can  graphically  show  the  JTIDS 
Links  and  Nets  to  and  from  AOC_GW  and  JTIDS_SAT_GW.  Visualization  of  the  GIESim  JTIDS 
networking  components  for  the  DMSD  is  extremely  valuable,  and  makes  for  a  far  richer  demonstration. 

A  new  Predator  UAV  icon  was  also  created  for  JTIDS.  An  external  simulation  provided  by  SAIC 
“flys”  the  Predator  icon  over  the  Korean  terrain  in  the  JTIDS  simulation.  An  icon  for  an  AOC  was  also 
added.  The  AOC  icon  is  shown  in  Figure  7  in  a  later  section.  As  the  UAV  flies,  it  is  connected  to  the  AOC 
icon  by  a  line  that  represents  a  different  communication  channel.  The  dynamically  moving  UAV  in  the 
JTIDS  simulation  makes  for  a  much  more  “integrated”  and  interesting  demonstration. 


GSS  JTIDS  Sim  GSS  SAT_COM  Sim 


Pub  601 
MSG_RCVD 
for  Strike  Platform 


Figure  3  -  GSS  Simulation  GIESim  Elements  and  HLA  IDs 
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4.2  OVERVIEW  OF  PSI  DEVELOPMENTS 


Figure  4  shows  an  illustration  of  the  work  items  accomplished  by  PSI  for  the  GIESim  SAB  Demo 
and  the  different  components  within  each  simulation  in  support  of  GIESim. 
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CONNECl 
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SAT  GW 

HOST 
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To/From  Other 


CHANNEL* 
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To/From  Other 


GEISim  Sims 
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Messages 


Send  Msg  To/From 
Send  Msg  From/T o 
(PSI  GSS  Defined) 


GEISim  Sims 


: 

Messages 


Figure  4  -  PSI  Work  Accomplished  for  GIESim  SAB  Demo 


The  PSI  JTIDS  Simulation  was  modified  to  include  two  gateways  to  route  messages  through  the 
JTIDS  network.  Specific  Operational  Nets  were  defined  for  this  purpose  as  discussed  in  a  later  section.  The 
AOC  Gateway  (AOC_GW)  routes  messages  received  from  HLA  through  JTIDS  to  either  an  FI 5  Strike 
platform  or  to  the  Korean  Satellite  Gateway  (SAT  GW)  for  sending  to  the  CONUS.  The  JTIDS  SAT  GW 
connects  to  the  PSI  SAT_COM  simulation  via  a  GSS  IP  Channel  interface.  Conversely,  messages  received 
from  SAT_COM  via  the  IP  Channel  interface  are  routed  by  the  SAT  GW  through  JTIDS  for  delivery  at  the 
AOC_GW.  The  AOC_GW  then  publishes  an  HLA  interaction  for  reception  by  another  GIESim  Simulation 
player.  In  addition,  the  AOC  GW  can  receive  a  reply  message  over  JTIDS  from  a  Strike  Platform  for 
publishing  over  HLA. 

The  PSI  SAT_COM  Simulation  was  modified  to  include  a  control  interface  for  use  with  STK,  and 
gateways  to  buffer  and  route  messages  from  the  IP  Channels  and  HLA  interfaces  over  the  satellite  network. 
Furthermore,  PSI  SAT_COM  was  modified  to  show  a  2D  representation  of  both  the  whole  earth  and  Korea. 

Each  PSI  simulation  computes  it’s  own  contribution  to  message  latency  and  adds  this  to  the 
accumulating  message  latency  prior  to  sending  over  the  network  interface. 
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In  addition  to  developments  completed  within  JTIDS,  SAT  COM,  and  STK,  PSI  set-up  a  hub- 
based,  network  architecture  similar  to  that  planned  for  the  GIESim  SAB  Demo  in  order  to  debug  and 
validate  models  and  simulation  performance  prior  to  the  dry-run  in  Rome. 
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4.3  HLA  INTERFACE  AND  TEST_DRV  DEVELOPMENT 

PSI  developed  a  GSS  implementation  of  the  five  HLA  Interactions  defined  for  the  GIESim  SAB 
demo.  The  GSS  architecture  for  the  HLA  interface  is  shown  in  Figure  14  in  Appendix  A.  GSS  provides 
built-in  support  for  HLA  interactions  making  the  architecture  to  support  the  GIESim  HLA  interactions 
rather  simple.  For  each  HLA  interaction,  we  define  a  resource  with  the  same  name  as  the  interaction  -  this 
automatically  subscribes  GSS  to  this  particular  interaction  name.  We  also  define  an  HLA  event  handler 
that  handles  HLA  subscribe  events  by  calling  the  appropriate  process  for  the  received  interaction.  To 
publish  an  interaction,  we  load  data  into  the  resource  and  PUBLISH  it.  GSS  automatically  generates  the 
“.fed”  FOM  file. 

As  a  means  to  test  and  verify  the  HLA  implementation,  PSI  developed  an  HLA  Test  Driver  to 
exercise  the  publishing  and  subsequent  subscribing  of  the  HLA  interactions.  Figure  15  in  the  Appendix 
shows  this  GSS  architecture.  This  test  driver  makes  heavy  use  of  GUI  panels  to  display  published  and 
subscribed  data.  The  use  of  panels  in  GSS  is  very  easy,  and  makes  understanding  data  easy  compared  to 
simple  print  statements.  The  architecture  of  the  complete  TEST_DRV  simulation  that  combines  our  HLA 
implementation  with  the  HLA  Test  Driver  is  shown  in  Figure  15  in  the  Appendix.  TEST_DRV  also 
contains  developmental  models  for  using  the  GSS  Channel  capabilities  between  JTIDS  and  SAT_COM. 
This  functionality  is  not  currently  exercised  in  TEST_DRV.  The  HLA  Test  Driver  uses  a  main  control 
panel  to  display  publish  and  subscribe  statistics.  This  panel  is  shown  in  Figure  5. 

This  panel  presents  a  count  of  all  interactions  published  and  received,  and  presents  separate  counts 
of  published  and  received  events  for  each  of  the  five  interactions.  The  Message  Window  shows  HLA 
traffic  activity  and  stamps  each  event  as  a  “PUB”  or  “RFC”,  its  interaction  name,  and  time  of  occurrence. 
Published  events  are  tagged  with  an  ‘A’  for  an  automatically  generated  event  or  with  an  ‘M’  for  a  manually 
generated  publish  event. 

As  shown  in  Figure  5,  this  panel  provides  buttons  to  manually  publish  individual  interactions  and 
check  boxes  to  cause  each  interaction  to  be  generated  automatically.  The  check  boxes  labeled  “DISP” 
enables  the  display  of  separate  panels  that  show  data  for  interactions  as  they  are  published  and  received. 
Examples  of  the  panels  for  the  ENTITY  STATE  interactions  are  shown  in  Figure  6.  The  left  side  of 
Figure  6  shows  a  manual  publish  data  panel  for  one  instance  of  TEST  DRV  with  ID  56,  and  right  side  of 
Figure  6  shows  a  receive  data  panel  for  an  instance  of  TEST  DRV  with  ID  337. 
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Figure  5  -  Main  GUI  of  PSI's  HLA  Test  Driver  -  TEST_DRV 


The  TEST  DRV  tool  is  designed  to  be  executed  multiple  times  so  that  one  instance  can  publish  an 
interaction  and  another  can  “catch”  it  as  a  subscribed  event.  Each  data  panel  is  labeled  with  the  ID  for  the 
TEST  DRV  instance  it  is  associated  with. 

TEST  DRV  was  used  for  interoperability  testing  that  took  place  with  other  GIESim  team-member 
simulations.  The  components  of  TEST  DRV  were  incorporated  into  the  PSI  JTIDS  and  SAT  COM 
simulations  to  handle  pub/sub  of  HLA  interactions  with  the  other  simulations  in  the  GIESim  SAB  Demo. 
The  GUI  panel  capabilities  were  retained  in  JTIDS  and  SAT_COM  to  facilitate  testing  and  data  verification 
whenever  needed.  During  the  SAB  demo,  these  panels  will  be  hidden  unless  there  is  value  to  showing  the 
HLA  exchange  of  messages. 
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Publish  Data  Panel  Receive  Data  Panel 

For  TEST  DRV  ID  56  For  TEST  DRV  ID  337 

Figure  6  -  GSS  Panels  for  Pub/Sub  of  HLA  Interactions 
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4.4  JTIDS  SIMULATION  DEVELOPMENTS  FOR  GIESIM 

PSI  completed  the  JTIDS  model  development  and  integration  required  for  the  GIESim  SAB 
Demo.  Figure  7  shows  a  screen  shot  of  the  modified  JTIDS  simulation.  The  following  work  items  were 
completed  on  the  JTIDS  simulation  for  GIESim: 

1 .  The  Korean  package  scenario  was  modified  to  include  an  AOC  Gateway  (AOC_GW)  and  SAT 
Gateway  (SAT  GW).  Both  are  equipped  with  JTIDS  radios.  These  platforms  are  represented  as 
icons  as  shown  in  Figure  7.  Each  gateway  has  a  receive  and  transmit  buffer.  Messages  that 
exceed  available  buffer  capacity  are  dropped.  Messages  are  sent  across  the  JTIDS  network  at  the 
rate  and  in  segments  sized  for  the  characteristics  of  the  operational  net  being  used.  The  gateways 
perform  message  segmentation  and  reassembly,  and  count  messages  sent,  received,  dropped 
(buffer  full)  or  lost  (in  the  JTIDS  network).  Associated  with  each  gateway  are  panels  that  show 
buffer  size,  current  fill  level,  and  counts  of  sent,  received,  dropped,  and  lost  messages.  The  panels 
are  updated  dynamically  as  conditions  change.  Figure  8  shows  these  panels  in  more  detail.  Note 
that  each  panel  was  captured  at  a  different  time.  The  background  coloring  of  the  panel  is  intended 
to  reflect  the  source  of  the  message  traffic.  Panels  for  messages  originating  from  a  ground  source 
are  yellow  color.  Panels  for  messages  coming  in  over  JTIDS  are  colored  blue.  The  bright  color 
scheme  was  chosen  for  impact  and  clarity. 

2.  Sets  of  Operational  Nets  were  defined  with  the  PSI  JTIDS  Operational  Network  Planning  Tool  for 
use  in  the  SAB  Demo.  Table  I  lists  these  nets  along  with  their  characteristics. 

a.  Nets  104  and  107  are  high  speed  nets  for  fast  transmission  of  image  data,  and  have  a 
maximum  throughput  of  19.2  Kbps. 

b.  Nets  103  and  106  are  very  slow  nets  and  were  intended  to  demonstrate  image 
transmission  latencies  that  were  much  longer  than  the  performance  requirements.  In  dry- 
run  testing,  the  high  speed  nets  are  found  to  be  better  suited  to  the  SAB  Demo,  so  use  of 
the  low  speed  nets  was  dropped. 

c.  Net  105  is  intended  to  convey  a  message  to  an  F15  strike  platform  from  the  AOC,  and 
Net  102  is  intended  to  convey  a  response  from  the  strike  platform. 


Table  1-  JTIDS  Operational  Nets  Defined  for  GIESim  SAB  Demo 
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Figure  7  -  JTIDS  Simulation  with  GIESim  Demo  Modiflcations 


AOC  GW  Panel 


SAT  GW  Panel 
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Figure  8  -  JTIDS  Gateway  Panels 

3.  The  new  Operational  Nets  for  GIESim  were  combined  with  existing  operational  nets  for  the 
Korean  scenario  and  were  then  run  through  the  PSI  Time  Slot  Assignment  tool,  which 
automatically  determined  time  slot  assignments  for  all  the  nets.  The  resulting  time  slot 
assignments  were  then  used  in  the  JTIDS  Simulation.  In  Figure  7,  the  nets  for  the  AOC_GW, 
SAT_GW,  and  Strike  Platform  are  shown  as  orange  (direct  path)  and  yellow  (relayed  path). 

4.  The  JTIDS  Simulation  is  set-up  as  an  IP  Server  for  a  pair  of  IP  Channels  that  connect  it  to  the 
SAT_COM  simulation.  Two  channels  were  used  to  permit  full  duplex  message  passing  between 
the  simulations,  this  allows  messages  to  pass  simultaneously  in  both  directions. 

A  model  was  added  to  the  JTIDS  simulation  to  “fly”  a  UAV  Predator  icon  as  directed  by  HLA 
Entity  State  interactions  received  (i.e.,  subscribed  to)  from  another  simulation.  The  UAV  icon  can  be  seen 
in  Figure  7.  In  addition,  an  icon  for  the  “AOC”  was  created  and  added  to  the  simulation  to  illustrate  the 
AOC  in  Korea,  and  a  dynamically  updated  line  connects  the  AOC  icon  with  the  UAV  icon  as  it  moves. 

As  a  result  of  the  August  interoperability  dry-run  at  AFRL  Rome,  it  was  concluded  that  dynamic 
setting  of  the  JTIDS  Gateway  buffer  sizes  would  be  desirable,  as  this  capability  would  improve  the  SAB 
Demo.  Consequently,  a  GSS  function  button  in  the  JTIDS  simulation  was  programmed  to  invoke  a  Panel 
for  changing  the  size  of  the  ingoing  and  outgoing  buffers  on  both  the  AOC  and  SAT  gateways.  Figure  9 
shows  this  new  Panel  along  with  the  new  function  button  and  the  AOC  Panel  before  and  after  buffer  sizes 
were  changed. 
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> 
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Figure  9  -  JTIDS  Gateway  Buffer  Size  Panel 
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4.5  SAT  COM  SIMULATION  DEVELOPMENTS  FOR  GIESIM 


Several  modifications  were  made  to  the  PSI  SAT_COM  Simulation  in  support  of  the  GIESim 
SAB  Demo.  The  most  notable  modification  was  the  development  of  an  interface  to  STK  to  obtain  satellite 
orbit  and  connectivity  data.  The  following  list  presents  the  work  accomplished  on  PSI  SAT  COM  for  the 
GIESim  demo: 

1 .  PSI  completed  the  interface  between  SAT  COM  and  STK  using  the  IP  CONNECT  interface  on 
STK.  This  work  involved  the  addition  of  STK  APIs  into  SAT  COM,  understanding  and  loading 
the  appropriate  data  structures  to  send  to  STK,  and  unpacking  of  data  structures  received  from 
STK.  PSI  set-up  the  STK  server  to  show  several  views  (2D  and  3D)  of  the  satellite  constellations 
with  respect  to  the  earth  once  the  SAT_COM  client  connected  to  it.  SAT_COM  does  the 
following  with  respect  to  STK: 

a.  Initializes  the  STK  CONNECT  link  and  opens  the  STK  Viewer  on  a  separate  PC  running 
a  licensed  copy  of  STK  provided  by  AGE 

b.  Uploads  data  on  the  location  of  ground  stations  and  initial  satellite  positions. 

c.  Downloads  tables  of  satellite  position  and  connectivity  data.  This  essentially  compresses 
a  four  day  scenario  into  two  hours,  which  makes  for  a  more  interesting  (dynamic) 
display. 

d.  Uses  downloaded  information  to  generate  if  s  own  satellite  connectivity  lines  and 
positioning  of  satellite  icons. 

2.  An  HLA  interface  was  added  to  SAT  COM  to  subscribe  to  and  publish  GIESIM  MSG  SEND 
interactions.  This  interface  is  for  communication  with  other  simulations  in  the  GIESim  SAB 
Demo.  This  interface  can  also  monitor  and  generate  the  other  GIESim  HLA  interactions  if 
needed. 

3.  Two  GSS  Channel  Client  interfaces  were  added  for  bi-directional  communication  of  messages  to 
and  from  the  PSI  JTIDS  Simulation. 

4.  A  Korean  gateway  was  added  to  SAT_COM  that  will  handle  messages  from  the  PSI  JTIDS 
Simulation  via  the  Channel  interface  and  send  them  on  the  satellite  “uplink”  in  Korea.  Messages 
received  on  the  Korean  “downlink”  are  sent  to  JTIDS  through  the  Channel  interface.  This  gateway 
has  panels  that  show  buffer  fill  levels  that  are  updated  dynamically. 

5.  A  gateway  located  in  CONUS  was  added  to  SAT_COM  to  handle  messages  from/to  the  external 
simulations  connected  by  HLA.  This  gateway  receives  message  via  HLA  and  sends  them  on  the 
satellite  “uplink”  to  Korea,  and  gets  messages  from  the  satellite  “downlink”  in  CONUS  then 
publishes  them  as  HLA  interactions.  This  gateway  also  has  panel  that  show  buffer  fill  levels  that 
are  updated  dynamically. 

6.  SAT_COM  was  modified  to  show  two  different  background  overlays.  One  shows  a  2D  view  of 
the  whole  earth,  and  the  other  view  shows  the  terrain  of  Korea.  Views  are  selected  through  a 
button  in  the  graphics  window.  Both  views  support  dynamic  updates  of  satellite  connectivity  lines 
between  satellites  and  to  ground  stations.  Figure  10  and  Figure  1 1  are  screen  shots  from 
SAT_COM  of  the  world  and  terrain  views  respectively. 
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Figure  10  -  SAT_COM  World  View 
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Figure  11  -  SAT  COM  Korean  Terrain  View 

4.5.1  STK  Interface  and  Data  for  GIESim 

As  mentioned  in  a  prior  report,  PSI  negotiated  with  AGI  to  obtain  licenses  for  STK  5.0  for  use  in 
the  GIESim  SAB  Demo.  STK  5.0  provides  API  and  interfacing  descriptions  for  their  IP-based  CONNECT 
interface.  PSI  studied  this  material  and  built  an  interface  to  the  CONNECT  interface  into  SAT_COM.  PSI 
completed  the  following  work  on  STK  for  the  GIESim  SAB  Demo  project: 

1 .  Obtained  licenses  and  installed  STK  on  two  PSI  machines  -  one  of  which  is  dedicated  to  the 
GIESim  project  and  demo. 

2.  Tested  the  STK  CONNECT  interface  and  set-up  several  views  in  the  STK  Server/Viewer  for  the 
GIESim  Demo. 

3.  Uploaded  data  on  ground  station  locations  and  satellite  data  to  STK. 

4.  Downloaded  satellite  orbital  and  connectivity  data  from  STK. 

5.  Tested  with  SAT_COM  and  in  conjunction  with  JTIDS  and  a  Test  Driver  simulation. 

Figure  12  shows  the  STK  screen  showing  views  of  the  satellite  orbits  defined. 


Figure  12  -  STK  Screen  Shot  for  GIESim 
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4.6 


SIMULATION  TESTING  BY  PSI 


4.6.1  In-House  Testing 

In  order  to  test  the  various  simulation  components  built  by  PSI  for  GIESim,  PSI  assembled  a  test 
configuration  very  similar  to  that  planned  for  the  SAB  Demo.  This  configuration  is  shown  in  Figure  13. 
Four  PC’s  were  used,  with  each  dedicated  to  one  function  or  simulation.  Fach  PC  was  configured  with  an 
appropriate  IP  address,  and  the  HFA  RID  files  and  Server  IP  addresses  were  configured  accordingly.  One 
PC  (PC2)  ran  the  RTI  and  served  as  a  source  for  generating  HFA  interactions  for  testing.  PC2  also 
subscribed  to  all  GIFSim  interactions  and,  therefore,  monitored  and  verified  correct  publishing  of  HFA 
interactions  by  the  respective  simulations. 


PSI  GIESim  Test  Configuration 


PC1  PC2  PC3  PC4 


Figure  13  -  PSI  In-House  Test  Configuration  for  GIESim  Work 


Testing  proceeded  by  using  PC2  to  generate  HFA  interactions  first  intended  for  JTIDS.  The 
incoming  message  arrival  and  subsequent  transmission  through  JTIDS  and  arrival  at  the  SAT_GW  were 
tracked.  The  resulting  message  was  then  tracked  as  it  arrived  at  SAT_COM  through  the  GSS  Channel 
Resource  and  “flowed”  through  SAT_COM  to  the  CONUS  Gateway  that  published  the  message  as  an  HFA 
interaction.  PC2  was  then  used  to  test  in  the  opposite  direction  by  publishing  an  HFA  interaction  intended 
for  the  CONUS  Gateway  in  SAT_COM.  Message  flow  was  followed  through  SAT  COM,  into  the 
SAT  GW  in  JTIDS,  through  the  JTIDS  network  and  into  the  AOC  GW  in  the  JTIDS  Simulation  where  it 
was  published  as  an  HFA  interaction.  Fatencies  were  checked  along  with  HFA  interaction  ID  fields. 

PC2  also  published  HFA  interactions  for  the  F15  Strike  Platform  in  JTIDS  through  the  AOC_GW 
and  verified  that  it  replied  to  the  AOC_GW  by  observing  a  GIFSIM_MSG_RCVD  interaction  published  by 
the  AOC_GW. 

PC2  was  also  used  to  generate  multiple  messages  to  verify  correct  behavior  of  the  gateways  and 
transmission  through  JTIDS  and  SAT_COM.  PC2  was  also  used  to  generate  extraneous  HFA  interactions 
to  verify  that  JTIDS  and  SAT_COM  appropriately  ignored  them. 

The  test  configuration  was  also  used  to  verify  correct  “flying”  of  the  Predator  UAV  in  response  to 
received  GIESIM  ENTITY  STATF  interactions.  The  Test  Driver  was  modified  to  generate 
GIESIM  ENTITY  STATE  interactions  with  FAT  FON  coordinates  associated  with  a  circular  flight  path 
centered  on  Korea. 
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Several  refinements  were  made  to  a  few  internal  components  and  were  then  verified  to  be 
operating  correctly.  In  addition  to  the  HLA  Test  Driver  on  PC2  having  the  ability  to  subscribe  or  publish 
HLA  interactions,  both  JTIDS  and  SAT_COM  have  the  same  capability  since  they  employ  the  same  HLA 
interface  developed  by  PSI  for  use  in  the  GIESim  SAB  Demo.  This  allows  tracking  and  publishing  of  HLA 
messages  from  each  simulation  to  verify  message  arrival  (and  publishing)  as  needed.  This  feature  of  the 
modified  JTIDS  and  SAT_COM  simulations  proved  useful  during  the  dry-run  testing  that  took  place  in 
Rome  in  late  August. 


4.6.2  Internet  HLA  Interoperability  Tests 

On  July  29,  2003  an  HLA  interoperability  test  took  place  between  a  simulation  running  at  PSI  in 
NJ  and  a  simulation  running  at  SAIC  in  Ohio.  SAIC  ran  the  RTI  in  Ohio.  After  a  couple  of  very  minor 
glitches,  all  five  interactions  were  successfully  published  and  subscribed,  and  over  1000  interactions  were 
successfully  exchanged.  All  fields  and  sub-fields  of  the  five  HLA  interactions  were  validated  in  the 
exchange.  PSI  sent  a  copy  of  if  s  HLA  Test  Driver  (TEST  DRV)  to  SAIC. 


4.6.3  Dry  Run  Interoperability  Testing  at  AFRL  Rome 

PSI  took  part  in  a  successful  dry-run  of  the  multi-simulation  demonstration  at  AFRL  Rome  on 
August  26^^  and  27^^.  Only  minor  tuning  of  the  JTIDS  and  SAT  COM  simulations  was  needed.  When  the 
demo  scenario  was  run  we  found  that  the  low  speed  nets  originally  planned  to  demonstrate  “failure  to  meet 
performance  requirements”  were  really  not  needed.  Instead,  Dr.  Debany  felt  that  the  ability  to  show 
dropped  messages  as  a  result  of  a  gateway  buffer  being  too  small  made  for  a  more  effective  demonstration. 
Subsequently,  the  JTIDS  simulation  was  modified  to  support  dynamic,  real-time  user  settable  gateway 
buffer  sizes.  Also,  the  gateway  GUIs  were  modified  to  show  dropped  (buffer  full)  and  lost  (JTIDS 
dropped)  messages  in  addition  to  the  number  of  messages  successfully  sent  and  received. 

At  the  time  of  writing  this  Final  Report,  another  dry-run  of  the  full  DMSD  (including  JBISim)  is 
scheduled  for  Oct  14-15  at  AFRL  Rome.  This  should  be  the  final  “dress  rehearsal”  for  the  SAB  Review 
now  scheduled  for  mid  November. 
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5. 


LESSONS  LEARNED 


The  DTIG  Multi-Simulation  Demonstration  (DMSD)  was  built  for  the  SAB  Review  as  a  proof-of- 
concept  or  first  demonstration  of  the  GIESim  concept  of  a  modeling  and  simulation  framework  for 
satisfying  the  needs  for  complex  communications  and  information  system  simulations.  In  addition,  the 
process  of  defining,  designing,  building,  testing,  integrating  and  running  the  DMSD  provided  both 
validations,  challenges  and  insights  into  the  concepts  and  Framework  of  GIESim.  The  GIESim  leadership 
team  was  interested  in  lessons  learned  from  the  creation  of  the  DMSD.  Lessons  learned  as  stated  in  the  list 
below  are  from  the  perspective  of  PSI  gathered  from  working  with  the  GIESim  team  and  from  developing 
additional  models  for  our  existing  simulations.  These  “lessons”  have  been  shared  with  the  GIESim  team, 
and  for  the  most  part  reflect  similar  “findings”  by  the  other  team  members.  They  have  not  been  “endorsed” 
by  the  team,  and  are  therefore  solely  the  view  point  of  PSI. 

•  It  is  an  order  of  magnitude  or  more  cheaper  (in  time  and  dollars)  to  assemble  a  multi-simulation 
communications  capability  by  drawing  from  existing  models  and  simulations. 

•  The  use  of  existing  models  and  simulations  does  not  eliminate  the  need  for  domain  or  subject 
matter  experts.  There  is  still  a  need  for  experts  to  define  and  develop  the  target  analytical  system: 

o  Experts  in  the  models  and  simulation  environments  and  tools 
o  Experts  in  the  systems  being  modeled 

o  Expertise  in  reducing  system  needs  and  requirements  to  the  selection  of  appropriate 
models/simulations/environments  and  scenarios.  (See  below) 

•  Model  requirements  and  multi-simulation  architecture  must  be  defined  based  on  requirements  and 
needs  of  the  target  analysis  that  is  to  be  accomplished.  Validity  should  be  looked  at  as  a  quality 
process  with  each  simulation/model  component  impacting  quality  in  a  potentially  multiplicative 
way. 

•  Existing  models  and  simulations  may  (and  probably  will)  need  tailoring  to  meet  the  needs  of  the 
each  experiment.  Thus,  a  simulation  environment  that  supports  ease  of  use  and  understandability 
is  essential.  Good  architectural  designs  are  also  needed.  Some  points  to  consider  include: 

o  Definition  and  development  of  IP  Interfaces,  and  HLA  interfaces  with  associated 
Interactions,  etc.,  with  of  IP  Addresses  and  required  simulation  and  entity  IDs. 
o  Definition  and  development  of  metrics  and  capabilities  to  collect  them,  e.g.,  latency. 

These  metrics  may  require  new  models  or  tailoring  of  existing  model  to  gather  and  report 
to  the  multi-simulation  environment. 

o  Definition  and  development  of  means  to  interact  with  a  simulation  to  introduce  controlled 
flaws,  outages,  etc.  to  explore  overall  impacts  on  the  communications  system  being 
studied.  Means  might  include  real-time  feeds,  access  to  data  files,  user  interaction  with 
the  running  simulation,  and  multiple  simulation  runs, 
o  Definition  and  development  of  appropriate  visualization  capabilities  to  support  both 
testing  and  analytical  experiments. 

•  Scenario  development  and  equipment  collections  must  be  defined  and  potentially  developed  for 
the  multi-simulation  environment.  This  will  require: 

o  A  common  definition  of  what  is  meant  by  “scenario”, 
o  Import  of  terrain  for  area  of  interest. 

o  Flight  paths  and  other  movement  paths  for  dynamic  communications, 
o  Definition  and  implementation  of  network  characteristics  (connectivity,  network 
capabilities,  redundancies,  etc.). 

o  Traffic  generators  and  other  means  to  stimulate  the  simulation  environment  in  realistic 
ways. 

o  The  GIESim  multi-simulation  environment  may  need  to  interface  with  external 
simulation  systems  and  take  scenario  inputs  from  them, 
o  Many  other  variations  and  considerations  are  likely. 
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•  Testing  to  ensure  interoperability  and  validity  is  required  and  must  be  scheduled  into  the  program. 
A  layered  approach  can  help  to  minimize  the  number  of  variables  and  conditions  being  tested. 

•  Potential  modifications  of  models  and  simulations  may  be  needed  as  identified  during  testing  and 
during  analytical  experiments,  e.g.,  need  to  have  the  ability  to  change  buffer  sizes.  Ease  of  use  of 
the  simulation  environment  is  critical  for  this. 

•  Many  terms  and  parameters  need  to  be  defined.  Here  are  a  number  of  examples: 

o  We  may  often  talk  about  multiple  fidelity  models,  but  what  does  fidelity  really  mean  and 
how  should  we  quantify  it.  Furthermore,  how  do  (or  should)  we  translate  customer 
needs  into  an  assessment  of  model  fidelity  requirements?  How  should  the  “fidelity”  of 
one  model  be  factored  into  the  fidelity  of  other  (potentially)  interacting  models  when 
addressing  the  requirements  for  a  communications  simulation  solution, 
o  Model  and  simulation  performance  needs  to  be  quantified.  The  GIESim  approach  to 
building  complex  communications  simulations  can  certainly  cut  development  time  and 
build  times.  In  some  (perhaps  many)  cases,  execution  times  may  be  equally  or  more 
important.  To  attain  statistical  validity  over  a  range  of  operating  conditions  and 
situations,  a  GIESim  simulation  environment  will  need  to  be  exercised  over  many 
variations  of  scenarios  and  parameters.  Hence,  model  and  simulation  execution 
performance  may  become  critical  factors  in  selecting  the  tools  for  a  particular  simulation, 
o  Performance  versus  fidelity  trade-offs  are  often  discussed.  In  some  cases  high  fidelity 
models  may  run  faster  than  low  fidelity  models,  and  therefore  satisfy  both  speed  and 
fidelity  requirements. 

As  GIESim  evolves,  these  kinds  of  lessons  learned  and  newer  considerations  must  be  taken  into 
account,  particularly  since  there  is  a  desire  to  automate  and  stream-line  the  entire  simulation  “realization 
process”.  The  next  section  expands  on  this  view  and  provide  suggestions  for  future  work  leading  to  the 
success  of  GIESim. 
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6. 


SUGGESTIONS  FOR  FUTURE  WORK 


PSI  feels  strongly  that  GIESim  has  great  potential  to  be  “the”  place  to  go  to  get  answers  to 
complex  communications  and  information  questions  that  require  sophisticated  simulations  to  answer.  In 
FY04,  the  AFRL  GIFSim  leadership  is  looking  to  extend  and  expand  on  the  work  done  in  FY03  on  the 
creation  of  the  GIESim  Architectural  Framework.  The  themes  for  FY04  are  along  the  lines  of  “faster, 
cheaper,  better”.  More  specifically,  one  objective  is  to  '"further  refine  and  evolve  the  GIESim  architecture 
to  enhance  support  for  the  investigation  and  analysis  of  communication  topologies  for  GIE\ 

When  it  comes  to  architecture  definition,  requirements  analysis,  scenario  planning  and 
simplification  of  scenario  developments,  metric  definitions,  performance,  etc.,  PSI  feels  strongly  that  it  is 
important  to  consider  the  needs  of  real  potential  customers  and  systems.  Such  a  “contexf  ’  is  vital  to  setting 
realistic  directions  for  GIESim  and  for  maintaining  a  good  focus. 

In  addition  to  expanding  on  the  DMSD,  here  are  some  considerations  for  future  FY04  work: 

•  Focus  on  the  needs  of  DTIG  and  those  of  other  tactical  systems  to  provide  a  more  concrete  and 
grounded  framework  for  directing  the  evolution  of  GIESim,  otherwise  work  may  tend  to  get  too 
abstract. 

•  Re-evaluate  of  the  purpose  of  GIESim  as  originally  laid  out  by  Dr.  Debany,  and  reflect  on  how  our 
goals  may  have  changed.  This  will  keep  us  somewhat  customer  focused  and  goal  oriented. 

•  Create  a  list  of  GIESim  attributes  that  would  attract  customers  and  reflect  highly  on  GIESim 
within  both  the  scientific  and  operational  communities.  Perhaps  listing  what  we  see  as  benefits  of 
GIESim  from  the  perspectives  of  potential  customers  and  clients  is  on  par  with  the  importance  of 
integrating  COTS  and  GOTS  simulation  components.  Why  should  a  ’’customer”  care  about 
GIESim,  and  what  is  the  cost/benefit  relationship  that  will  bring  clients  to  GIESim?  Here  are 
some  of  the  potential  ’’selling  points”  for  GIESim: 

o  GIESim  is  an  enabler  of  communications  simulation  and  modeling  needs.  Dr.  Debany 
once  said  that  some  people  think  simulation  is  too  expensive  and  doesn’t  work,  whereas 
others  think  all  needed  simulations  are  already  done.  Reality,  as  we  know,  is  somewhere 
in  between.  GIESim  can  be  a  valuable  source  of  what  is  possible  in  the  world  of  building 
communication  simulation  solutions  -  for  a  reasonable  price  and  in  a  reasonable  time 
frame. 

o  GIESim  can  be  used  to  analyze,  cost  out,  assemble,  integrate  and  deliver  communications 
modeling  needs  of  tactical  and  operational  systems  (existing  and  planned),  and  of  large 
Force-on-Force  simulations  faster,  cheaper,  easier  and  with  higher  fidelity  than  through 
any  other  means. 

o  The  GIESim  team  and  lab  has  demonstrated  the  successful  ability  to  bring  disparate 
simulations  together  to  prove  its  approach.  The  team  will  continue  to  accumulate 
expertise  and  models  to  make  simulation  solutions  of  complex  communications  needs  be 
realized  faster  and  cheaper. 

o  GIESim  is  the  place  to  go  to  understand  the  state  of  the  art  in  M&S  for  communications 
systems. 

o  GIESim  has  codified  and  will  continue  to  codify  and  refine  the  practices,  approaches, 
standards,  etc.  to  build  simulation  solutions  quickly. 

•  With  the  above  said,  specific  ’’customer”  needs  and  some  large  Force  level  simulations  should  be 
explored  to  understand  what  they  need  and  how  we  might  need  to  interface  with  them.  Doing  so 
should  help  us  with  all  aspects  of  the  FY04  work  from  requirements  analysis  to  development. 

Some  potential  customer  needs  might  include: 

o  Execution  speed 

o  Fidelity  (how  do  they  define  this) 
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o 


Types  of  questions  they  want  answered  and  the  time  frames  in  which  they  need  the 
answer,  and  the  form  they  want  the  answers  in:  numeric,  charts,  real-time  graphics,  etc. 
o  What  models,  scenarios,  inputs,  metrics,  etc.  are  required  to  support  their  needs? 
o  What  are  their  interface  requirements?  (systems,  databases,  user,  etc.) 

■  Based  on  the  above  the  GIESim  team  can  then  ask: 

o)  How  does  our  ’’architecture”  and  current  assembly  of  models  and  simulations  support  these 
customer  needs?  What  changes  may  be  needed? 

o)  What  capabilities  (documents,  automation’s,  etc.)  are  needed  to  facilitate  these  kinds  of 
customer  needs? 

The  reason  that  PSI  feels  that  a  customer  oriented  approach  is  valuable  is  that  it  provides  a  much 
better  context  to  address  the  kinds  of  things  that  are  being  discussed  for  the  FY04  work  program.  For 
instance,  with  respect  to  looking  for  ways  to  'deduce  the  time  required  to  implement  scenarios....",  this 
type  of  thrust  is  best  addressed  with  respect  to  an  investigation  of  actual  needs,  and  opens  questions  about 
what  is  meant  by  a  ’’scenario”. 

From  the  perspective  of  PSI,  GIFSim  is  ultimately  (or  should  ultimately  be)  a  provider  of 
communications  simulation  solutions.  We  need  to  keep  this  in  mind,  otherwise  our  efforts  could  easily 
become  an  abstract  software  development  in  search  ”of  ’  an  application. 

Another  consideration  for  FY04  GIESim  is  testing.  How  do  we  determine  that  a  complex 
arrangement  of  simulations  is  in  fact  working  as  intended?  Testing  and  validation  should  be  something  that 
is  considered  going  forward,  particularly  if  GIESim  gets  some  paying  customers. 

The  GIESim  concept  and  Architectural  Framework  are  great  and  have  the  potential  to  fill  the  void 
in  communications  modeling  and  simulation  needs  that  exist  today,  and  that  will  become  greater  in  the 
years  ahead  as  the  nature  of  war  and  military  power  changes  and  as  the  OPTEMPO  continues  to  increase. 
Furthermore,  the  use  of  complex  communications  systems  such  as  JTIDS  is  expected  to  increase,  and  the 
need  for  better,  more  timely,  and  cost  effective  communications  modeling  tools  and  Frameworks  such  as 
GIESim  will  grow.  PSI  is  committed  to  the  success  of  the  GIESim  effort  and  looks  forward  to  working  the 
GIESim  team  in  FY04. 
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7. 


SUMMARY  AND  CONCLUSIONS 


PSI  proactively  participated  in  the  definition  and  realization  of  the  GIESim  Lab  multi-simulation 
demonstration  for  the  SAB.  PSI  took  part  in  team  conference  calls,  and  several  face-to-face  planning 
sessions  in  Rome.  PSI  made  many  contributions  to  the  GIESim  HE  A  Interactions  that  were  defined  for  the 
GIESim  HLA  “backbone”,  to  the  scenario  that  was  defined  for  the  DMSD,  and  to  the  support  material  for 
the  SAB  Review.  PSI  designed,  developed,  and  tested  new  interfaces  and  models  for  GIESim  that  were 
added  to  the  GSS  JTIDS  and  SAT  COM  simulations.  PSI  took  part  in  interoperability  testing  of  the 
DMSD  over  the  internet  and  at  Rome  on  a  number  of  occasions.  PSI  also  built  key  GUI  interface  panels 
that  effectively  display  activity  of  message  traffic  through  the  network.  The  JTIDS  simulation  in  particular 
was  the  graphics  visualization  center  piece  for  the  DMSD. 

Specific  design,  development  and  test  work  completed  by  PSI  for  the  GIESim  DMSD  include: 

•  The  addition  of  the  following  components  to  both  JTIDS  and  SAT_COM: 

o  HLA  and  GSS  Channel  interfaces. 

o  Two  gateway  hosts  in  each  simulation. 

o  Graphic  interfaces  in  each  to  show  message  arrival  and  transmission. 

•  For  the  JTIDS  Simulation: 

o  Defined  Operational  Nets  to  support  communications  between  gateways  for  GIESim  message 
traffic. 

o  Added  those  nets  to  the  nets  already  defined  for  the  Korean  scenario. 

o  Used  the  Time  Slot  Assignment  tool  to  automatically  generate  time  slots  for  all  nets  for  use  in 
the  JTIDS  Simulation. 

o  Added  unique  icons  for  the  AOC  and  SAT  gateways. 

o  Added  icons  for  an  AOC  and  for  a  Predator  UAV  that  is  controlled  via  HLA. 

•  For  SAT  COM: 

o  Developed  an  interface  to  control  and  use  STK  to  obtain  satellite  orbit  and  connectivity  data 
and  to  show  2D  and  3D  views. 

o  Added  a  2D  world  view  and  view  of  the  Korean  terrain  to  SAT_COM  for  the  GIESim  SAB 
Demo. 

•  Conducted  several  tests  of  interoperability  between  the  JTIDS,  SAT_COM  and  STK  using  an 

isolated  hub  and  an  HLA  test  driver  simulation. 

•  Took  part  in  interoperability  tests  of  our  HLA  interface  over  the  internet,  and  at  dry-runs  of  the 

DMSD  in  Rome. 

Through  monthly  reports  PSI  documented  progress  and  contributions  to  the  GIESim  project  and  to 
the  DMSD.  PSI  contributed  expertise  in  modeling  and  simulation  gained  through  building  solutions  for 
many  satisfied  DoD  customers  to  the  evolution  and  success  of  GIESim.  PSI  contributed  lessons  learned  in 
both  documented  and  verbal  forms,  and  was  a  co-creator  of  the  SAB  “story”.  PSI  also  participated  in 
discussions  and  made  contributions  to  the  definition  of  a  FY04  work  program.  PSI  looks  forward  to 
continued  participation  with  GIESim  and  to  continued  success  with  the  program. 

APPENDIX  A  -  SIMULATION  ARCHITECTURES 


This  appendix  presents  the  simulation  architectures  of  the  various  simulations  employed  by  PSI 
for  the  GIESim  DTIG  Multi-Simulation  Demonstration  (DMSD).  The  architecture  of  each  simulation  is 
briefly  described  with  specific  additions  and  modifications  that  PSI  needed  to  support  the  DMSD  scenario 
highlighted. 

One  of  the  many  unique  and  powerful  characteristics  of  the  General  Simulation  System  (GSS) 
developed  by  PSI  and  used  in  the  DMSD  includes  the  ability  to  visualize  software  in  a  computer  aided 
design  (CAD)  drawing.  A  simulation  developer  must  define  a  simulation  architecture  via  a  GSS  drawing 
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before  any  software  can  be  developed.  PSI  encourages  development  of  architecture  along  physical  lines, 
and  GSS  makes  this  easy  to  do.  Another  unique  characteristic  of  GSS  is  the  ability  to  define  hierarchical 
models.  This  is  analogous  to  the  hierarchies  often  found  in  physical  and  natural  systems.  The  architectures 
of  the  JTIDS  simulation  and  of  the  SAT_COM  simulation  reflect  the  structure  of  JTIDS  radios,  and 
communications  systems. 

In  GSS,  model  hierarchies  can  be  nested  as  deeply  as  needed,  and  can  be  restructured  easily  as  the 
simulation  evolves.  At  the  lowest  levels  of  the  model  hierarchy  are  elementary  models.  Elementary 
models  contain  processes,  e.g.,  rules  that  change  state,  and  resources  that  contain  data  and  state 
information.  Processes  are  shown  as  rectangles,  and  resources  are  shown  as  rounded  rectangles.  Only 
those  processes  that  are  connected  by  lines  to  specific  resources  have  access  to  data  within  those  resources. 
It  is  this  separation  of  processes  from  data  that  allows  the  software  architecture  to  be  drawn.  Furthermore, 
once  at  the  elementary  model  level,  a  user  can  immediately  access  process  rules  or  data  within  resources 
with  an  editor  by  double-clicking  on  them.  These  features  of  GSS  directly  connect  architecture  to  the 
underlying  software!  This  is  a  powerful  capability  unique  to  GSS. 

The  ability  to  visualize  simulation  architectures  dramatically  improves  comprehension  of  the 
simulation,  which  in  turn  dramatically  improves  productivity  and  also  enables  very  effective  software 
model  reuse. 

In  the  sections  that  follow,  you  will  see  that  key  model  elements  developed  in  support  of  DMSD 
appear  in  each  of  the  PSI  simulations.  To  support  GIESim,  PSI  developed  new  models  using  a  layered 
approach.  These  new  models  were  then  “imported”  into  the  main  JTIDS  and  SAT_COM  simulations  and 
tailored  as  needed. 
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A.l  GSS  TEST_DRV  SIMULATION 

The  central  design  feature  of  the  GIESim  DMSD  called  for  the  use  of  HLA  to  interconnect  the 
various  simulation  components  from  the  different  team  members.  This  required  the  team  to  define  a  set  of 
HLA  interactions  and  associated  simulation  and  entity  ID  numbers. 

GSS  has  built-in  support  for  HLA  Interactions,  which  makes  the  use  of  HLA  Interactions  quite 
simple  and  easy,  figure  14  shows  the  HLA  interface  developed  by  PSI  to  handle  the  DMSD  HLA 
Interactions.  With  GSS  an  HLA  Event  Handler  is  defined  that  fields  published  events.  Events,  in  this  case 
five  HLA  Interactions,  are  “subscribed”  to  by  creating  a  resource  of  type  “HLA”  for  each  interaction  and 
with  the  same  name  as  the  HLA  Interaction.  When  an  HLA  Interaction  is  published  by  another  simulation 
that  matches  one  of  the  five  HLA  Interactions  (resources),  then  the  HLA  Event  Handler  will  call  a  process 
to  handle  that  interaction.  Also,  the  HLA  resource  can  be  “published”,  which  causes  an  HLA  Interaction  to 
be  published. 

figure  15  shows  the  HLA  Test  Driver  Model.  This  model  was  developed  to  test  the  PSI 
implementation  of  the  GIESim  HLA  Interactions  and  contains  the  GUI  Panels  that  were  shown  earlier  in 
this  final  Report.  With  GSS,  constructing  GUI  interfaces  is  very  easy  and  is  a  preferred  means  to  present 
data  and  to  take  inputs  from  a  user. 

In  order  to  exercise  the  HLA  Interface  and  HLA  Test  Driver  models,  they  were  placed  in  a 
simulation  named  TEST  DRV.  TEST  DRV  was  built  so  that  several  instances  of  the  simulation  could  be 
running  on  a  single  PC,  or  on  separate  PCs.  This  allowed  one  TEST  DRV  simulation  to  publish  HLA 
Interactions  for  another  TEST  DRV  simulation  to  receive  or  “subscribe”  to.  This  was  an  extremely 
effective  means  of  testing  PSPs  implementation  of  the  GIESim  HLA  Interactions,  and  was  extremely 
useful  in  inoperability  testing  with  the  other  GIESim  simulations.  We  could  very  easily  and  quickly 
determine  which  of  the  HLA  Interactions  had  been  published  and  analyze  message  content.  TEST  DRV 
can  generate  or  publish  HLA  Interactions  as  needed  to  stimulate  the  other  simulations  during  testing. 

The  hierarchical  HLA  Interface  Model,  consisting  of  the  GIESIM  HLA  INTERLACE  and  the 
HLA  TEST  DRIVER  models,  were  exported  and  then  imported  into  the  JTIDS  and  SAT  COM 
simulations.  Hence  these  simulations  were  given  the  full  capabilities  of  the  TEST  DRV. 

Also  shown  in  figure  15  are  a  number  of  other  models.  The  UAVLLYER  model  was  designed 
to  take  HLA  Entity  State  Interactions  and  “fly”  an  icon  for  a  Predator  UAV  in  the  JTIDS  simulation.  The 
UAV  DRIVER  was  designed  to  test  the  UAV  LLYER.  The  other  model  shown  is 
CHANNEL  INTERLACE.  PSI  had  decided  to  exchange  messages  between  the  JTIDS  and  SAT  COM 
simulations  using  our  IP  Channel  capability.  This  was  done  to  demonstrate  other  means  to  interconnect 
simulations.  These  models  were  developed  in  TEST_DRV  and  exported  to  JTIDS  and  SAT_COM,  and  are 
not  actively  used  in  TEST  DRV. 
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Figure  14  -  GSS  HLA  Interface  for  GIESim 
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A.2  GSS  JTIDS  SIMULATION 


The  PSI  created,  GSS-based  JTIDS  simulation  is  an  “industrial”  or  “operational”  strength 
simulation  of  the  complex  JTIDS/Link-16  radio,  and  supports  detailed  simulation  of  message  exchange 
over  JTIDS  Links  and  Operational  Nets  in  complex  equipment  scenarios.  JTIDS  uses  a  highly  accurate  RF 
propagation  model  that  accounts  for  the  underlying  terrain. 

GSS  JTIDS  is  the  center  piece  of  the  GIESim  DMSD.  In  addition  to  the  detailed  functionality  it 
provides,  it  also  offers  a  rich,  interactive  Run-Time  Graphics  (RTG)  environment.  RTG  is  a  built-in 
capability  of  GSS.  GSS  JTIDS  is  the  main  visualization  component  within  the  GIESim  DMSD.  Figure  16 
shows  the  architecture  of  the  GSS  JTIDS  simulation,  and  indicates  the  portion  of  the  complex  model 
hierarchy  that  was  added  for  GIESim,  i.e.,  the  GIESIM  INTERFACES  model.  In  addition  to  the  HLA 
Interface  discussed  in  the  preceding  section  of  this  Appendix,  the  GIESIM  INTERFACES  model  also 
contains: 


•  IP  interfaces  to  the  SAT  COM  simulation  (IP  SERVER  MODEL) 

•  A  gateway  to  and  from  the  AOC  into  the  JTIDS  network,  and  a  gateway  to  and  from  the  JTIDS 

network  to  the  Satellite  network  (GIESIM  GATEWAY  model) 

•  UAV_FLYER  model  to  “fly”  an  icon  of  a  Predator  UAV  over  the  Korean. 

These  models  are  shown  in  greater  detail  in  Figure  17.  JTIDS  has  two  IP  Servers  that  use  the  GSS 
IP  Channel  capability.  One  server  is  for  messages  into  JTIDS  from  the  SAT_COM  simulation,  and  the 
other  is  for  messages  bound  for  SAT_COM  from  JTIDS. 

The  AOC  and  SAT  COM  Gateways  handle  message  segmentation  and  reassembly  (SAR)  that  is 
needed  to  get  a  large  UAV  image  message  through  the  JTIDS  network.  The  SAR  function  is  sized  by  the 
characteristics  of  the  JTIDS  Operational  Net  being  used.  Each  Gateway  has  a  GUI  Panel  that  shows  in¬ 
bound  and  out-bound  message  statistics  (sent,  dropped,  lost,  received)  as  well  as  buffer  size  and  current 
buffer  fill  levels.  These  GUIs  are  updated  dynamically.  A  separate  GUI  is  provided  to  “resize”  the 
gateways  as  needed  to  demonstrate  the  effect  of  the  buffer  being  too  small  at  first  and  then  being  increased 
to  prevent  messages  being  dropped.  The  Gateways  are  responsible  for  the  calculation  of  message  latency 
within  JTIDS.  Figure  18  shows  the  details  of  the  AOC_GW  Model  and  if  s  associated  GUI  Panel.  The 
SAT_GW  Model  for  the  satellite  gateway  is  virtually  the  same. 

Also  shown  in  Figure  17  is  a  small  model  that  is  responsible  for  connecting  the  GIESim  message 
traffic  into  the  simulated  JTIDS  network  via  the  host  interface  in  the  GSS  JTIDS  simulation.  Figure  19 
shows  the  associated  JTIDS  Host  Model  changes  made  to  support  sending  and  receiving  GIESim  messages 
through  the  JTIDS  simulation. 

As  can  seen  in  these  figures,  a  fair  amount  of  model  development  work  was  required  to  support 
the  requirements  for  the  GIESim  DMSD.  GSS  made  this  level  of  development  quite  fast  and  easy 
compared  to  other  languages  and  approaches  to  simulation.  As  GIESim  evolves  some  amount  of  new 
model  development  and  model/simulation  tailoring  will  likely  be  required  to  meet  the  visualization, 
scenario,  and  metrics  requirements  of  systems  being  modeled. 
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New  Hierarchical  Model  added  to  JTIDS  Simulation  for  GIESim 
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Figure  16  -  GSS  JTIDS  Simulation  Architecture 
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Figure  17  -  Detailed  Architecture  of  GIESim  Interfaces  in  JTIDS 
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Figure  18  -  AOC_GW  Model  in  JTIDS  with  AOC  Panel  Shown 
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New  Processes  and  Changes  to  JTIDS  Host  Message  Generator  for  GIESim 
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Figure  19  -  JTIDS  Host  Model  Changes  for  GIESim 
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A.3  GSSSAT  COM 


PSI  proposed  the  addition  of  satellites  into  the  DSMD  through  the  use  of  our  SAT_COM 
simulation.  Satellites  are  important  components  of  operational  scenarios,  and  a  communications  capability 
used  by  DTIG  and  other  systems.  PSI  also  offered  to  interface  SAT  COM  to  the  Satellite  Tool  Kit  (STK) 
from  AGI  to  obtain  satellite  orbits  and  connectivity  data.  As  stated  earlier  in  this  Final  Report,  this  work 
was  completed  successfully. 

Figure  20  shows  the  overall  architecture  of  the  SAT  COM  simulation  and  indicates  the  models 
added  to  support  the  DMSD.  SAT  COM  is  based  on  GSS  and  uses  RTG  for  visualization  of  connectivity, 
satellites,  political  borders,  and  terrain.  SAT_COM  uses  a  top-down  hierarchical  model  approach  to 
simulation  design  along  the  lines  discussed  in  the  preceding  section  on  JTIDS. 

Figure  21  shows  a  more  detailed  view  of  the  models  added  to  SAT  COM  for  the  GIESim  DMSD. 
SAT_COM  has  an  HLA  interface  to  communicate  with  the  other  non-GSS  simulations  in  the  DMSD.  This 
is  the  same  HLA  model  hierarchy  that  was  developed  in  the  TEST_DRV  simulation,  and  was  imported  into 
SAT_COM.  Only  minor  tailoring  of  a  couple  of  process  calls  was  needed  to  integrate  the  HLA  interface 
into  SAT  COM. 

Also  shown  in  Figure  21  is  the  CLIENT_MODULE  that  supports  two  IP  Client  interfaces  to  the 
JTIDS  IP  Server  interface.  This  module  uses  the  GSS  Channel  Resource  capability  that  makes  the  use  of 
IP  sockets,  i.e.,  channels,  very  easy  to  use.  One  channel  handles  messages  from  JTIDS,  and  another 
handles  message  to  JTIDS.  In  this  case,  the  “messages”  are  the  GIESim  HLA  Interactions  bundled  into  a 
data  attribute  or  block  with  a  message  type  header  to  distinguish  which  HLA  Interaction  is  being 
exchanged. 

The  SATELLITE  AND  GWS  model  contains  relatively  simple  models  of  the  Ground  Stations 
located  in  Korea  and  the  CONUS.  A  “bent-pipe”  satellite  model  sends  messages  received  on  the  up-links 
to  the  corresponding  down-links.  Messages  coming  from  JTIDS  arrive  over  the  IP  Interface  and  go  to  the 
Korea  Ground  Station  and  are  sent  to  the  CONUS  Ground  Station  via  the  bent-pipe  model.  At  the  CONUS 
the  message  latency  is  computed  and  added  to  the  HLA  Interaction  that  is  published.  Messages  sent  to 
SAT_COM  via  HLA  enter  the  CONUS  Ground  Station  gateway  and  flow  to  the  JTIDS  simulation  in  the 
reverse  direction.  GUI  Panels  associated  with  each  gateway  indicate  message  activity. 

The  interface  to  STK  required  the  creation  of  an  STK  CONTROL  model,  which  is  shown  in 
Figure  22.  STK  acts  as  an  IP  Server  by  virtue  of  their  CONNECT  interface.  The  SAT  COM 
STK  CONTROL  makes  an  IP  connection  to  the  STK  CONNECT  interface  and  then  controls  STK  to 
obtain  satellite  orbit  data  and  connectivity  data.  Due  to  the  non-interactive  nature  of  STK,  PSI  had  to 
manage  a  bulk  download  of  data  from  STK  which  was  stored  in  a  number  of  local  files,  and  uses  these  files 
to  interactively  access  data  and  subsequently  direct  STK  to  update  their  display  based  on  the  local  time. 
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GSS  SAT_COM  Additions  for  GiESim  SAB  Demo 
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Figure  20  -  GSS  SAT  COM  Architecture 
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Figure  21  -  Detailed  Models  added  to  SAT_COM  for  GIESim 
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Figure  22  -  SAT_COM  STK  Interface  Control  Model 
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